<html>
<head>
    <TITLE>Python 3.x support</TITLE>
</head>
<body>
    <h1>Introduction</h1>
    <p>
        pywin32 now supports Python 3.x. Note that the Python source code is
        maintained in Python 2.x syntax and automatically converted to Python
        3.x syntax using the 2to3 tool. Please don't submit patches etc using
        Python 3.x syntax.
    </p>

    <h1>Unicode everywhere</h1>
    <p>
        In general, pywin32 on Python 2.x will accept both str and unicode
        objects and convert as appropriate.   However, in py3k, bytes objects
        will generally not be accepted when a 'string' is required - the
        intent is to restrict usage of bytes objects in py3k to where bytes
        truly are meant.
    </p>
    <p>
        Most pywin32 modules for py3k are built with UNICODE defined, and
        thus will call the Unicode versions of the Windows API.
    </p>
    <h1>Specific module notes</h1>
    <h2>isapi</h2>
    <p>
        The isapi package supports py3k, but note that currently only the
        <code>redirector.py</code> sample has been converted to work in
        both environments - in particular, subtle urllib changes will
        probably require attention - see the redirector sample for details.
    </p>
    <p>
        Note that ISAPI itself is a narrow-character based API.  As a result,
        functions such as
        <a href="EXTENSION_CONTROL_BLOCK__GetServerVariable_meth.html">GetServerVariable()</a>
        etc all return bytes objects - it is up to the application to 
        interpret those bytes.  pywin32 detects server variables starting 
        with UNICODE_ and does return unicode objects in that case - see 
        the IIS documentation for more details.
    </p>
    <p>If you pass a unicode object to the ISAPI functions, it will be 
       automatically encoded using the default encoding rather than the
       'mbcs' encoding used by the rest of pywin32.  In general this should
       be avoided as IIS doesn't define an encoding.
    </p>

    <h1>datetime objects</h1>
    <p>
        Python 3.x builds use a subclass of datetime.datetime objects as the
        "native" datetime object; a subclass is used to provive a backwards 
        compatible <a href="PyDateTime__Format_meth.html">PyDateTime.Format</a>
        method, but otherwise the datetime object is identical to the base
        class. All time objects returned by pywin32 will have a UTC timezone
        (via the <a href="win32timezone.TimeZoneInfo__utc_meth.html">win32timezone.TimeZoneInfo.utc() method</a>),
        and times with any timezone will be accepted when passed to pywin32 -
        but "time zone naive" objects are *not* supported.
    </p>
    <p>
        Note that it is possible we will support "time zone naive" objects
        in the future, as supporting such objects in the future will be fully
        backwards compatible.  However, it is not yet clear that supporting
        such objects is helpful due to the ambiguities that may arise, and
        attempting to remove such support in the future would cause more
        problems than enabling it.
    </p>
    <p>
        The <a href="win32timezone__now_meth.html">win32timezone.now</a> and
        <a href="win32timezone__utcnow_meth.html">win32timezone.utcnow</a> methods
        may be useful when working with datetime objects.
    </p>
</body>
</html>
